Another idea would be for PRs to upload their binaries as usual and have the bloat check run in the scheduled process (we delete the outputs when bloats are generated). This would have the benefit of easily figuring out if a bloat report already ran or not.

Another idea would be for PRs to upload their binaries as usual and have the bloat check run in the scheduled process (we delete the outputs when bloats are generated). This would have the benefit of easily figuring out if a bloat report already ran or not.

I think @jwhui and the OpenThread team has some of these problems addressed. Are there solutions we can leverage there?

@jelderton @robszewczyk @hawk248 ?

Another idea would be for PRs to upload their binaries as usual and have the bloat check run in the scheduled process (we delete the outputs when bloats are generated). This would have the benefit of easily figuring out if a bloat report already ran or not.

I think @jwhui and the OpenThread team has some of these problems addressed. Are there solutions we can leverage there?

I believe the solution there was a github app - I had the link when we previously discussed this.
@jwhui - did you have any issues with fork repo permissions during the openthread bloat checker setup?

https://github.com/apps/size-report/ was mentioned in #541

https://github.com/apps/size-report/ was mentioned in #541

Docs are a bit light there. I believe I currently know what to do to make our bloaty-based reports work, however I cannot estimate what it takes to get size-report to work. I would prefer if someone else more familiar tries for the size-report integration and then we can compare (or if one approach seems a time sink, we should just keep with whatever we get working first)

@bukepo or @jwhui - do you want to try the path of making size-report work now that we are not a private repo anymore?

@andy31415 could you install the size-report app on this project, so that I can try bringing it up on this project?

@andy31415 could you install the size-report app on this project, so that I can try bringing it up on this project?

I don't think I have sufficient rights. @woody-apple: can we install the size-report app?

Separately, for this PR in particular: @saurabhst @jelderton @robszewczyk ?

@andy31415 could you install the size-report app on this project, so that I can try bringing it up on this project?

I don't think I have sufficient rights. @woody-apple: can we install the size-report app?

Done!

All committers have signed the CLA.

@andy31415 can you sign the CLA? we can merge then :)

This pull request fixes 2 alerts when merging dbc5cb7 into efa630b - view on LGTM.com

fixed alerts:

• 1 for Unused named argument in formatting call
• 1 for Unused import

This pull request fixes 2 alerts when merging 4351126 into ace290d - view on LGTM.com

fixed alerts:

• 1 for Unused named argument in formatting call
• 1 for Unused import

This will apparently require some iterations to fix - still unclear to me why builds fail since this was supposed to be a python only change.

This pull request fixes 2 alerts when merging 59daba0 into ace290d - view on LGTM.com

fixed alerts:

• 1 for Unused named argument in formatting call
• 1 for Unused import